新しいWell-Architectedフレームワークすべて読む勉強会を1年かけてやった感想をまとめる

こんにちは、臼田です。

みなさん、AWSのベストプラクティス意識してますか？(挨拶

今回は私が社内で1年かけて行ったWell-Architectedフレームワークの勉強会についてやったことや感想を紹介します。

だらだら書いていくのでご容赦を。

Well-Architectedフレームワークの話

タイトルに新しいって書いたのでそのあたりの話からしていきます。

Well-Architected(W-A)フレームワークはAWSのベストプラクティス集です。様々な場面で活躍します。そんなW-Aが新しくなったのはちょうど１年くらい前です。以下のブログで変更内容などは把握できると思います。

5つの柱自体は変わりませんが、その説明から、あり方から変わりました。設計原則も変わり、しっかりと確認する必要があるとこの時感じました。

そもそも1年前の私は上から下まで全部W-Aフレームワークを読んでいたわけではなかったので、この機会に読んでおこうと思いました。ただ一人でもくもくしてももったいないので、社内で勉強会にすることにしました。

ちなみに、W-Aってどんなものですかっていうところは以下のブログが非常にわかりやすいのでこちらを見てください。W-Aの構成解説やベストプラクティスを一覧にしています。

W-Aの見方

新しいW-Aフレームワークのドキュメントは1つではありません。以下6つが存在します。

• フレームワークの概要
• オペレーショナルエクセレンスの柱(運用上の優秀性の柱)
• セキュリティの柱
• 信頼性の柱
• パフォーマンス効率の柱
• コスト最適化の柱

原本はこちら。

まず確認すべきドキュメントは概要です。あとは柱毎に好きに確認します。概要自体にも柱の内容が書かれていますので、W-Aのことを知りたい、程度であれば概要のドキュメントだけでOKです。

各ドキュメントは昔はPDFでも提供されていましたが、今はPDFがアーカイブされてHTML版のみになりました。ただAWSのドキュメントページでPDF化されているので、それを確認することは可能です。以下から開けます。

HTMLで確認してもPDFで確認してもどちらでも良いと思います。見やすい方で。私は勉強会をやるときにはページ数指定がやりやすかったので、PDFで実施しました。

勉強会のやり方

勉強会の進め方は以下の感じです。

• 開催頻度: 週1回1時間の定期スケジュールを入れる
• 勉強会開始時:
  • W-Aのドキュメントの読む範囲を定義
  • みんなで同じ場所を10-15分程度で読む
  • 各自自由に読む
  • 読みながら以下のようなことをSlackのスレッドに書いていく
    • 気になったこと
    • よくわからないこと
    • 実際やるの難しくない？って思ったこと
    • こういう場合どうするの？って感じだこと
    • とかとか
• 読み終わったら:
  • みんなが書いている感想とか疑問とかを上から順番に拾う
  • わいわいディスカッションする

W-Aのドキュメントは概要だけでも100ページぐらいある超大作ですから、定期的な勉強会をスケジュールして、勉強会の中で読む時間を作らないと続かないと感じたので、私はこんな形式で実施しました。

私の場合は、参加メンバーは様々なお客様のAWS環境をみるソリューションアーキテクトがほとんどであったため、読むときの観点は上記のようになりました。勉強会で集まるメンバーによっては観点をもう少し具体的にしてもいいと思います。例えば自分たちのプロジェクトに照らし合わせながら具体的な課題や現状とのギャップについて感じたことを書いていくのもいいと思います。

大事なことはとりあえず全部読むって決めて、この毎週1時間だけしっかり集中することです。事前準備も不要にすることで継続が簡単になると思います。もちろん集まりが悪くなるときにはスキップしたりしました。

Zoomの録画機能を使って動画を残しておいたので、参加できなかったメンバーもどんな話をしたか確認できるようにしました。毎回中途半端なところで区切らないでキリのいいスコープを定義することで、1回参加しなくても次参加しやすくしました。

概要を一通り読んだところで終えてもいいと思いますし、よりブレイクダウンしたところまで行きたければ各柱の詳細ドキュメントを確認してもいいと思います。その時は1年がかりですが。概要だけであれば2ヶ月程度で一通り読んでディスカッションできると思います。

どんなことを話したか

残念ながら私の記憶力は非常に残念なのと、よく都合よく雰囲気で覚えちゃうので感覚で書き起こしていきます。

全般的に胸に刺さる言葉が多い

ベストプラクティス集なので、「ああ、まったく正しいベストプラクティスだ」となります。

私達はいろんなお客様とお仕事しているので、全般的に正論がきついことはあります。クラウド活用の道のり、つまりクラウドジャーニーはお客様毎に違うので、クラウドジャーニーの具合によって、どこまでやってどこまではやらないか、みたいな話が全般的によくありました。

例えば順序的に一発目に来る、運用上の優秀性の柱の「組織」というベストプラクティスではチームがビジネスを成功させるためにそれぞれの役割を理解したり、適切にコミュニケーションする必要があったりすると書かれています。うーん正論。

でも大事なことをちゃんと書いてくれているのは嬉しいところもあります。クラウド活用ってこういうところから始まるとも言えるので、いい材料にはなります。

トレードオフはやっぱり難しい

最初の方に「セキュリティと運用上の優秀性は、通常、他の柱とトレードオフできません。」とあります。要所要所でトレードオフの判断基準を助けるような文言もあります。

書いてあることに納得することもあれば、そうじゃないきがするなーと思うときもあります。

まず上記のセキュリティがトレードオフにならないってところも、いやいやセキュリティもできることに限度があるし様々なレベルがあるのでそう簡単にトレードオフできないとは言えないよなぁとか。

AWSだけのベストプラクティスじゃない

とどのつまりITに関する、あるいはビジネスに関するベストプラクティスでもあるなーと。

もちろんAWSの詳細なベストプラクティスもあるわけですが。

だからこそ、特に私の立場では難しいなーと思うわけです。AWSの支援をしながらAWS以外の話もしていく必要があるのです。でもそれが大事だよね。

例えばセキュリティの柱の原則ではID管理の話から始まりますが、IDの話はAWSの中もそうだし外もそうなので簡単じゃないなーと思うわけです。

 

他にも色々あった気がしますが、まあこんなところで。

まとめ

Well-Architectedフレームワークをちゃんと読んだことありますか？

得るものはいっぱいあるので、ぜひ勉強会とかもくもく会とかいろいろ理由をつけて読んでみてください。

私も色んな人と話してみたいです。背景が違う人と話すとより楽しいですよ。